[00:14.060 --> 00:19.000]  Alright folks, it's almost the end. But here we are again.
[00:19.680 --> 00:25.640]  Wanted to take a quick second and give a big thanks to our 2020 sponsors.
[00:25.640 --> 00:29.720]  That's Checkmarks, Google, and Offensive Security.
[00:29.720 --> 00:33.560]  Thank you all so much for helping to make the AppSec Village happen.
[00:33.740 --> 00:35.900]  We could have done it without you.
[00:37.160 --> 00:39.540]  If you haven't gotten your shirt yet,
[00:39.540 --> 00:45.140]  go to appsecvillage.com and pick up your t-shirt.
[00:46.720 --> 00:51.060]  Also, if you're interested in making sure that this is a lasting thing,
[00:51.060 --> 00:53.820]  go out and become a SuperFan for us.
[00:53.860 --> 00:57.440]  That would go a long way towards helping to make sure that
[00:57.440 --> 01:01.280]  hopefully if next year's DEF CON is in person,
[01:01.280 --> 01:03.380]  AppSec Village will be part of it.
[01:03.820 --> 01:08.320]  Alright, without any further introduction or me talking,
[01:08.320 --> 01:13.340]  we are going to hear a talk from Mehmet Enes,
[01:14.240 --> 01:18.560]  Managing Partner at Invictus in Cyber Intelligence.
[01:18.560 --> 01:22.260]  He's going to be talking about A Haven for Hackers,
[01:22.260 --> 01:25.980]  Breaking a Web Security Virtual Appliance.
[01:25.980 --> 01:29.940]  With that, please help me welcome to the stage, Mehmet.
[01:29.940 --> 01:33.500]  Let's talk about finding zero-day vulnerabilities.
[01:33.500 --> 01:37.980]  In that presentation, I'm trying to take you all to the journey
[01:37.980 --> 01:43.260]  with me to finding different vulnerabilities in a security solution
[01:43.260 --> 01:47.660]  and a combination of them will give us a remote code execution
[01:47.660 --> 01:49.500]  with a root user.
[01:50.040 --> 01:55.580]  This is Mehmet. I've been doing vulnerability researching since 2005
[01:55.580 --> 02:01.260]  and I'm working for a company, Invictus Cyber Security and Intelligence.
[02:01.260 --> 02:03.880]  This is my Twitter address, mdisec.
[02:03.880 --> 02:08.020]  And pentest.blog is a webpage where me and my teammates
[02:08.710 --> 02:13.320]  are sharing our technical research in here.
[02:13.500 --> 02:16.840]  Okay, so, A Haven for Hackers, third edition.
[02:16.840 --> 02:23.840]  Actually, there's a story behind that title and it has started back in 2017.
[02:24.120 --> 02:29.140]  I was doing a pentesting for a company and there was a blue team member
[02:29.140 --> 02:32.520]  and they were telling me, you are doing this, etc.
[02:32.520 --> 02:39.320]  And I was thinking about what happens if we somehow manage to break in
[02:39.320 --> 02:45.700]  to your product that they are using and write a custom rule
[02:45.700 --> 02:48.700]  in order to become totally invisible.
[02:48.700 --> 02:51.980]  Because they are telling us what they are seeing in the product
[02:51.980 --> 02:55.900]  and if we become invisible, that would be so nice.
[02:55.900 --> 03:00.080]  So, that idea led me to finding remote code execution
[03:00.080 --> 03:04.920]  on various different seam and log management solutions back in 2017.
[03:05.480 --> 03:10.580]  And after one year, I was trying to send an email to a friend of mine
[03:10.580 --> 03:14.640]  and that dude was not receiving any email from me at all.
[03:14.640 --> 03:19.580]  And it turned out that there was a problem on the email security gateways
[03:19.580 --> 03:23.640]  and they managed to solve the problem and eventually we started sending
[03:23.640 --> 03:27.220]  an email to each other and I was thinking that,
[03:27.220 --> 03:29.900]  all right, there is an email security gateway product
[03:29.900 --> 03:35.320]  and what happens if I manage to break into your email security gateways
[03:35.320 --> 03:40.100]  so that I can read all the emails incoming and outgoing.
[03:40.100 --> 03:47.840]  So, that idea motivated me to finding a zero-day remote code execution vulnerabilities
[03:47.840 --> 03:52.100]  on Symantec, MacroFocus, and the Tranq macro.
[03:52.140 --> 03:56.460]  And the previous year, I was working with another client
[03:56.460 --> 04:00.780]  and the project was hardening the client's network
[04:00.780 --> 04:06.060]  in order to find data exfiltration scenarios.
[04:06.060 --> 04:10.460]  And they were telling me we have the web security solutions
[04:10.460 --> 04:13.540]  and only that device can connect to the internet
[04:13.540 --> 04:16.400]  so all the clients have to go through that box
[04:16.400 --> 04:21.780]  and if you find a different way to exfiltrate the data, that would be nice.
[04:21.780 --> 04:27.140]  And I was like, okay, so what happens if you find another zero-day vulnerability
[04:27.140 --> 04:31.360]  on especially the web security and the content filtering solutions.
[04:31.640 --> 04:37.500]  So, when the attacker managed to execute a code on the client network
[04:37.500 --> 04:40.880]  for the data exfiltration and the CT communication phase
[04:40.880 --> 04:44.300]  they can exploit the content filtering solutions.
[04:44.300 --> 04:46.400]  So, this is today's topic.
[04:46.400 --> 04:48.860]  We are going to talk about the zero-day vulnerabilities
[04:48.860 --> 04:54.280]  that I found on a very, very interesting product.
[04:54.320 --> 04:57.080]  And I have a case study for you.
[04:57.760 --> 05:03.660]  There is a product from the Trend Macro, InterScan Web Security Virtual Appliance
[05:03.660 --> 05:08.540]  and I have done the vulnerability research on specifically that solution
[05:08.540 --> 05:12.920]  and we are going to see what kind of vulnerabilities that I managed to find
[05:12.920 --> 05:16.600]  and using all of those vulnerabilities together
[05:17.240 --> 05:21.380]  we are going to see some sort of code executions in the end.
[05:21.380 --> 05:25.900]  But, before diving into the case study, I would like to talk a little bit about
[05:25.900 --> 05:30.460]  what is the content filtering in order to make it crystal clear to everyone.
[05:30.460 --> 05:33.680]  As you can see in the picture, there is a computer on the left
[05:33.680 --> 05:36.940]  which represents a client's network of the company.
[05:37.020 --> 05:43.700]  And those devices don't have a direct internet access.
[05:43.700 --> 05:46.360]  So, they have to go to the proxy service first
[05:46.360 --> 05:49.200]  and that proxy service goes to the internet
[05:49.200 --> 05:53.940]  so that the organization can do some sort of analysis
[05:53.940 --> 05:56.620]  and the rules on the client's network.
[05:56.620 --> 06:00.500]  So, content filtering is happening in here right now.
[06:00.500 --> 06:02.800]  We can imagine that the content filtering solutions
[06:03.440 --> 06:08.240]  they are kind of spatially implemented proxy service
[06:08.240 --> 06:12.500]  and the term is given to do controlling the type of web content
[06:12.500 --> 06:16.820]  that employees, guests, customers can access
[06:16.820 --> 06:20.480]  while they are connected to the business wired or wireless network
[06:20.480 --> 06:25.740]  so that the business may want to apply control over the type of content
[06:25.740 --> 06:33.560]  that can be accessed to stop employees by restricting access to certain type of web pages.
[06:33.560 --> 06:38.800]  And on top of that, also the content filtering is quite a good place
[06:38.800 --> 06:43.120]  to ensure malicious web pages cannot be accessed
[06:43.120 --> 06:49.240]  such as those used for phishing, malicious, distributing malware, etc.
[06:49.490 --> 06:57.140]  So, we are targeting that kind of products in this presentation.
[06:57.140 --> 07:01.860]  So, at the beginning, I had two main motivations
[07:01.860 --> 07:07.100]  like targeting web filtering solutions, why we are doing this.
[07:07.100 --> 07:11.240]  First and foremost, obviously, you know, all the clients network
[07:11.240 --> 07:14.560]  are going to the internet through that solutions.
[07:14.560 --> 07:18.360]  That means if we manage to break in, we are going to see the whole
[07:18.360 --> 07:21.500]  clients network internet traffic of the organization.
[07:21.940 --> 07:24.860]  And second motivation is, as I told you before,
[07:24.860 --> 07:28.320]  clients computer don't have a network access to the internet,
[07:28.320 --> 07:31.060]  they must go through the web filter.
[07:31.160 --> 07:35.000]  So, we need to find a better way to CT communication
[07:35.000 --> 07:37.360]  in the red teaming scenarios.
[07:37.360 --> 07:42.500]  And I believe web filter solutions is a quite secure and stealth way
[07:42.500 --> 07:44.700]  to make a CT communication.
[07:45.380 --> 07:49.860]  Of course, there is a lot of different approach like DNS beaconing, etc.
[07:50.060 --> 07:54.860]  But I believe that is a very secure and stealth way.
[07:55.760 --> 08:00.000]  So, all right, that is the brief introduction to the idea
[08:00.800 --> 08:02.480]  and the main motivation.
[08:02.480 --> 08:05.420]  And this is the methodology that I usually follow
[08:05.420 --> 08:08.620]  for my vulnerability research projects.
[08:08.720 --> 08:12.980]  And there is a seven steps and we're going to see every single step
[08:12.980 --> 08:16.240]  in details throughout the case study.
[08:16.320 --> 08:19.780]  And first and foremost, we have to find a way to get a free trial
[08:19.780 --> 08:23.040]  of the product that we are going to do vulnerability research on it.
[08:23.040 --> 08:28.380]  Because you have to, you know, break into your operating system level
[08:28.380 --> 08:31.320]  and you need to find all the source code and etc.
[08:31.320 --> 08:34.380]  And you have to test your vulnerabilities
[08:34.380 --> 08:36.480]  and eventually you're going to implement exploits
[08:36.480 --> 08:39.100]  for the vulnerabilities you found.
[08:39.100 --> 08:42.680]  So, you have to find a way to get a free trial
[08:42.680 --> 08:44.540]  and it's not quite easy, guys, always.
[08:44.540 --> 08:45.480]  It's not quite easy.
[08:45.480 --> 08:49.420]  It's sometimes and most of the times it requires to have a lot of meetings
[08:49.420 --> 08:51.200]  with the sales team.
[08:51.540 --> 08:55.880]  And if you find a free trial of the product,
[08:55.880 --> 08:58.300]  I strongly suggest you to start by reading the documentation
[08:58.300 --> 09:02.200]  because there is administrative documentation of this type of solutions
[09:02.200 --> 09:06.800]  and there is a huge technical information about the product itself.
[09:06.860 --> 09:14.820]  So, after that, we are going to find a way to have a root SSH access to the box
[09:14.820 --> 09:17.460]  because we are going to do the vulnerability research
[09:17.460 --> 09:22.240]  and most of the case there is operating level hardening
[09:22.240 --> 09:26.020]  and we need to get rid of all of those hardening stuff.
[09:26.020 --> 09:29.380]  And after that, you know, you are in a situation
[09:29.380 --> 09:32.020]  where you managed to install the solution,
[09:32.900 --> 09:36.680]  you read the documentation and you managed to overcome
[09:36.680 --> 09:40.220]  the operating level system hardening
[09:40.220 --> 09:44.440]  and that is the moment that you need to start using product itself
[09:44.440 --> 09:46.320]  like a regular user
[09:46.320 --> 09:49.680]  because you have to understand all the features
[09:49.680 --> 09:53.660]  because those information will become so handy
[09:53.660 --> 09:57.020]  when you need to define a possible attack vector.
[09:57.020 --> 10:00.520]  So, after that, we are going to talk about the enumeration
[10:00.520 --> 10:02.980]  and the configuration step
[10:03.500 --> 10:07.420]  and the most important phase is the defining possible attack vectors
[10:07.420 --> 10:10.120]  because you got all the information you need
[10:10.420 --> 10:13.560]  and it is a time to building attack scenarios
[10:13.560 --> 10:16.520]  and then find a vulnerability as a final step.
[10:16.520 --> 10:20.580]  We are going to see every single step throughout our case.
[10:20.580 --> 10:23.300]  And in that case, I mean the TRANQ macro
[10:24.140 --> 10:26.520]  Intersecam Web Security Virtual Appliance
[10:26.520 --> 10:31.660]  6.5 version. You can download it from the vendor web page.
[10:32.160 --> 10:34.720]  So, getting a free trial was quite easy
[10:35.440 --> 10:37.540]  specifically in that case.
[10:37.540 --> 10:41.060]  If you go to the Google and looking for the administrative documentation
[10:41.060 --> 10:43.820]  is an important keyword in here for the Google search
[10:44.760 --> 10:47.940]  you can directly find the administrative file
[10:47.940 --> 10:51.340]  which is usually like 300 pages.
[10:51.440 --> 10:54.240]  I strongly suggest you to read
[10:55.160 --> 10:56.940]  administrative documentation because
[10:56.940 --> 10:59.080]  you are going to see very very
[11:00.800 --> 11:03.340]  helpful information about the product.
[11:03.340 --> 11:04.780]  As you can see in here
[11:05.780 --> 11:08.900]  administrative documentation tells us there is
[11:08.900 --> 11:11.580]  different modes of the product. It can be
[11:11.580 --> 11:14.600]  transparent breach mode, it can be transparent
[11:14.600 --> 11:17.040]  breach mode with higher availability
[11:17.600 --> 11:20.560]  forward proxy, reverse proxy, iCAP
[11:20.560 --> 11:22.260]  WCCP, etc.
[11:22.780 --> 11:26.900]  That product can be installed in very different modes.
[11:27.140 --> 11:29.840]  On the right side, you are seeing the forward proxy mode
[11:29.840 --> 11:31.040]  which tells you
[11:31.040 --> 11:35.160]  that product can participate in a proxy chain
[11:35.160 --> 11:38.360]  forward all the traffic to the upstream proxy service
[11:38.360 --> 11:41.760]  and you will be seeing lots of graphics
[11:41.760 --> 11:45.200]  on the administrative documentation which will help you
[11:45.200 --> 11:48.660]  to understand about the product itself.
[11:48.660 --> 11:51.360]  So we are reading the funny manual as well
[11:51.360 --> 11:53.520]  and we
[11:53.520 --> 11:57.260]  of course, for the third step after reading the documentation
[11:57.260 --> 11:59.840]  you need to install the solution into your
[11:59.840 --> 12:02.780]  virtualization system.
[12:03.760 --> 12:06.560]  During the installation, there was an admin user
[12:06.560 --> 12:09.580]  and the password has been set during the installation
[12:09.580 --> 12:11.760]  and the product gives you
[12:12.390 --> 12:15.680]  an opportunity to do SSH connection to the box
[12:15.680 --> 12:18.500]  with the administrator user. But the problem is
[12:18.500 --> 12:21.420]  there was a restricted shell on the SSH
[12:21.420 --> 12:24.560]  there is very limited tools
[12:24.560 --> 12:27.860]  that you can use in the SSH interface of the product
[12:27.860 --> 12:30.340]  and we need to find a way to
[12:30.340 --> 12:33.960]  have a directly SSH connection
[12:33.960 --> 12:36.780]  with the root user because we are going to do
[12:36.780 --> 12:40.600]  remote debugging, we want to try to find out
[12:40.600 --> 12:43.500]  all the source codes and we are going to do
[12:43.500 --> 12:45.720]  further analysis, etc.
[12:45.920 --> 12:49.060]  So there is a little bit of a step before
[12:49.060 --> 12:51.600]  starting the vulnerability research.
[12:51.880 --> 12:54.840]  In that case, it was quite easy
[12:55.540 --> 12:58.880]  because the product was distributed
[12:58.880 --> 13:01.300]  by the vendor as an ISO file
[13:01.300 --> 13:03.880]  so you can directly install it into your VM
[13:05.100 --> 13:07.320]  and when you finish the installation
[13:07.980 --> 13:10.840]  the idea is you can detach the VM
[13:10.840 --> 13:14.380]  from the virtual machine that you just installed
[13:14.380 --> 13:17.820]  and then you can attach it to the different Linux machines
[13:17.820 --> 13:19.880]  and then you are going to mount
[13:20.140 --> 13:23.440]  a new disk and you are going to find a grab file
[13:23.440 --> 13:26.540]  because there was a password protection on the grab file
[13:26.540 --> 13:29.840]  and I want to get rid of that protection as well
[13:29.840 --> 13:33.080]  and you just need to remove the password protection
[13:33.080 --> 13:40.400]  line on the graph file. And after that, in order to get rid of the restricted shell thing,
[13:40.400 --> 13:46.520]  you can go to the SHT config file and you can enable remote root login. And if you do that,
[13:46.520 --> 13:51.060]  you need to go to the ETC task video file and add binbash for the root user, which will give
[13:51.060 --> 13:57.480]  us a direct SSH connection with the root user without having any restricted shell at all.
[13:57.480 --> 14:02.760]  And we have to undo every single thing that we have done so far. So that means
[14:02.760 --> 14:08.900]  you need to unmount this, detach the VM backup file, and attach it back to the original VM and
[14:08.900 --> 14:14.200]  reboot the machine, actually. And in that case, you are going to have the direct
[14:14.200 --> 14:22.080]  root SSH connection to the box. This is important. We need to get rid of, you know,
[14:22.080 --> 14:29.840]  operating level hardening. So we are kind of ready to start using product itself. In that case,
[14:29.840 --> 14:34.880]  I choose the reverse proxy mode, but I believe all the vulnerabilities that we have found,
[14:34.880 --> 14:42.940]  it exists no matter what is the installation mode at all. For the fourth step, I strongly
[14:42.940 --> 14:49.700]  suggest you to use a product for a day to get used to about the features itself, because
[14:49.700 --> 14:56.280]  there is a lot of functionality, as you can see in the picture. There is a URL access control,
[14:56.280 --> 15:02.880]  HTTP decryption. Right now, we know that product can't offload the SSL at all. That means we can
[15:02.880 --> 15:08.680]  deploy SSL through the administratory interface. And there is an advanced threat protection
[15:09.360 --> 15:15.040]  on the left side of the menu, as you can see. I hope you are seeing my mouse pointer in here.
[15:15.040 --> 15:21.680]  There is advanced threat protection. That means all the HTTP or HTTPS traffic will be analyzed
[15:21.680 --> 15:28.720]  by the product in order to find out malicious activities because of that feature. So later
[15:28.720 --> 15:34.860]  of that presentation, guys, we are going to see how important it is to understand and getting
[15:34.860 --> 15:40.620]  familiar with the product interface. Yeah, it's quite important. Just use it like a normal user.
[15:40.880 --> 15:47.000]  So we have a search access with a root user. So the initial step is always enumerating the
[15:47.000 --> 15:52.320]  services. This is what I'm doing. Of course, there would be a better way to do it, but this
[15:52.320 --> 15:58.780]  is my way to do. So I'm always looking for the nested command to find out what kind of services
[15:58.780 --> 16:09.280]  we have in the product itself. As you can see in here, there is a UWSGI, which listens for 6011.
[16:09.360 --> 16:15.520]  That means we are doing some sort of assumptions in that phase. So that most probably means
[16:15.520 --> 16:22.780]  there is a Python project running in the internal system. And there is a Java process which listens
[16:22.780 --> 16:29.320]  exact port of the administrator interface. That means we are going to deal with the Java
[16:29.320 --> 16:36.540]  when the time comes to do doing a research on the administrator interface. There's another UWSGI
[16:36.540 --> 16:44.100]  in here. And that is another important thing because as I said before, that product acts as
[16:44.100 --> 16:51.440]  proxy service. So that must be as some service on the product itself in order to handle incoming
[16:51.440 --> 17:00.880]  HTTP connections from the user. So IWSSD process that you are seeing in here, which listens for
[17:02.020 --> 17:09.300]  8080801. This is responsible for all the incoming connection from the client's network. So this is
[17:09.300 --> 17:16.520]  the majority part of the product itself because that is the one who is communicating with the
[17:16.520 --> 17:24.460]  clients. All right, so those are the services that we have in the product. But we need to find
[17:24.460 --> 17:32.960]  which of those services are allowed to communicate with the different computers in the network.
[17:32.960 --> 17:40.400]  Because in the end, we need to exploit at least one of those services. So what I'm doing
[17:40.400 --> 17:47.780]  to find out that information, I usually run an nmap scan from my main host to the product
[17:48.480 --> 17:56.340]  IP address. Or you can just use the IP tables dash dash list command to find out the IP
[17:56.340 --> 18:03.140]  tables rules. So according to that rule, most of the internal services have been forbidden
[18:03.820 --> 18:15.660]  to network traffic from the outside of the machine. You guys are remembering the IWSGI
[18:15.660 --> 18:23.260]  service. If you keep doing enumeration, we are seeing very interesting information in here.
[18:23.260 --> 18:29.060]  As you can see in here, there is a supervisor which is responsible for starting the solar
[18:29.060 --> 18:38.080]  service. So right now, we know there is Apache Solar and lots of Python services in the box. So
[18:38.080 --> 18:46.500]  what is Apache Solar? It is an open source enterprise search platform written in Java.
[18:46.500 --> 18:53.740]  It's a major feature is included full text search, highlighting the time indexing,
[18:53.740 --> 19:02.420]  dynamic clustering, etc, etc. So that means that Python project that we are seeing in here is
[19:02.420 --> 19:09.040]  responsible reading and writing the log file into the Apache Solar service. So most probably,
[19:09.040 --> 19:14.740]  whenever the request comes to the proxy service from the client's network, that proxy service is
[19:14.740 --> 19:19.560]  sending some sort of signals to the Python project that we have seen in here. It's
[19:19.560 --> 19:26.320]  something like an internal microservice. So that Python project is taking the information and
[19:26.320 --> 19:32.700]  writing it into the Apache Solar service. So whenever the administrator user tries to query
[19:32.700 --> 19:37.120]  something through the administrator interface, that request will be coming to the Python project
[19:37.120 --> 19:44.240]  as well. Because the naming convention in here says the dashboard parse, mains,
[19:44.240 --> 19:49.980]  stats parse, summary parse. There's a lot of log parsing and writing to the Apache Solar service.
[19:49.980 --> 19:56.800]  And whenever it needs to be accessed by the administrator interface, that Python project
[19:56.800 --> 20:02.420]  is taking the responsibility again. So it is quite important to know there is an Apache
[20:02.420 --> 20:08.960]  Solar service within the box. But unfortunately, due to the IP tables rule that we have in here,
[20:08.960 --> 20:15.180]  we're not going to be able to directly communicate with Apache Solar at the beginning. But later on
[20:15.180 --> 20:24.060]  the presentation, we will find a way to do it. So all right, let's talk about the IWSST process.
[20:24.060 --> 20:30.280]  If you grab it from the process tree, you are seeing the full path of the binary. And if you
[20:30.280 --> 20:38.380]  look for the file type, it is a symbolic link to the IWSST process, which is a SUID LFI
[20:39.060 --> 20:48.540]  binary. And there is a 61 module in that binary. So it's a very huge binary. And we can, of course,
[20:48.540 --> 20:55.820]  target that process. But it will be requiring lots of reverse engineering. So
[20:55.820 --> 21:01.960]  of course, we are going to do that at some point. But one of the most important attack
[21:01.960 --> 21:09.500]  surface, as you can imagine, it is the process itself. So, so far, I believe I just spent 20
[21:09.500 --> 21:21.120]  minutes, I guess. And we managed to collect enough level of information about product itself. So it
[21:21.120 --> 21:27.720]  is time to define attack vectors in a light of those information that we got so far.
[21:27.720 --> 21:33.920]  So we know that administrator interface is written with Java. And there is a proxy service,
[21:33.920 --> 21:41.320]  which is written with C++. I haven't told that before, but it is C++, guys. It's my best story.
[21:41.320 --> 21:48.400]  And there is a lot of internal services, but most of them are not accessible from outside of the box.
[21:48.400 --> 21:55.220]  And you guys are remembering, you know, SSL decryption and advanced threat protection
[21:55.220 --> 22:01.060]  features of the administrator interface. So we know that it does offloading the SSL,
[22:01.060 --> 22:10.140]  it parses HTML contents, scan files, et cetera, et cetera. So my idea at that phase, my idea was,
[22:10.140 --> 22:17.060]  okay, let's start with the administrator interface, and we can go after proxy service,
[22:17.060 --> 22:22.240]  if it needs to be, you know, let's start with the administrator interface at the beginning.
[22:22.500 --> 22:29.580]  But there is a lot of possible attack scenarios, as you can imagine, you know.
[22:30.280 --> 22:36.000]  One of the... if you want to, let's say, target the HTML parser of the product,
[22:36.000 --> 22:44.060]  like a browser exploitation, you can just send that phishing email to one of the employees of
[22:44.060 --> 22:50.200]  the company that contains a link. Whenever the user clicks on that link, that request will be
[22:50.200 --> 22:55.520]  sent to the proxy service, and proxy service is going to take that request from the client,
[22:55.520 --> 23:00.780]  and it's going to send exactly the same request to the destination server, which is a webpage that
[23:00.780 --> 23:08.660]  attacker can control. And whenever the proxy service gets the response, it performs analysis.
[23:08.660 --> 23:16.460]  It has to parse HTML content and scan the file. So that means you can directly attack to the HTML
[23:16.460 --> 23:22.940]  parser engine of the product, you know. There is a lot of different possible attack vectors,
[23:22.940 --> 23:28.300]  you know, that was just one example that just popped in my mind right now during the presentation.
[23:29.100 --> 23:33.000]  We are going to talk about the administrator interface, and then we're going to talk about
[23:33.000 --> 23:41.580]  the proxy service. You know, as you know, it is a Java project, and I love, I like to be working
[23:41.580 --> 23:46.800]  on the Java project. And every single time, whenever I'm facing with a Java application,
[23:46.800 --> 23:53.820]  I always start by reading the configuration file, because, you know, the web.xml, struct.xml,
[23:53.820 --> 24:00.500]  you know, all of those XML files contain a very good, high level of understanding information
[24:00.500 --> 24:08.040]  about the software that we are going to do vulnerability research. And I don't want to
[24:08.040 --> 24:15.060]  live in an SSH connection during vulnerability research, so we need to find out all the location
[24:15.060 --> 24:21.640]  of the jar file by using just find command on the step two. And then you can copy all of them
[24:21.640 --> 24:29.680]  to your main host to further analysis. Because we are going to deal with lots of jar files,
[24:29.680 --> 24:40.680]  and I strongly suggest you to use IDEs. I used to use gdgui for the compiling of the jar files,
[24:40.680 --> 24:47.140]  but those kind of project has hundreds of different jar files, and if you put all of
[24:47.140 --> 24:53.460]  those jar files into the gdgui, it wasn't working for me. It was just crashing or freezing,
[24:53.460 --> 24:58.700]  because it has to compile all the class and the functions, and they need to find all the cross
[24:58.700 --> 25:09.300]  calls. So I strongly suggest you to use IntelliJ or Eclipse for that purpose. And if you are up to
[25:09.300 --> 25:18.680]  use the IntelliJ IDE, there is a java.compiler.jar file under the compiler library, which comes by
[25:19.080 --> 25:28.320]  default with IntelliJ, I guess. And you can compile all the jar files under the lib folder.
[25:28.320 --> 25:36.340]  You can change the name, of course. And we are going to put all the compiled files under the lib-decompiled folder.
[25:36.600 --> 25:43.120]  And if you go to the IntelliJ interface and look for the project settings, there is a library
[25:43.120 --> 25:52.480]  section in here. You can import those libraries and sources all together, which will tell the
[25:52.480 --> 25:59.700]  IntelliJ, this is my Java software. IntelliJ will take the rest of the job. It's going to process
[25:59.700 --> 26:05.680]  all the classes, and you're going to be able to just find a function that you are interested in,
[26:05.680 --> 26:11.560]  and you will be just clicking it to go to the definition. And also you can find a very
[26:11.560 --> 26:19.240]  interesting function that might be some problem in the definition. You can just by using the IDEs,
[26:19.240 --> 26:24.560]  you can find all the different locations where this specific function has been called. So I
[26:24.560 --> 26:30.020]  strongly suggest you to be a friend with, you know, IntelliJ or Eclipse, if you are up to
[26:30.020 --> 26:41.000]  one little research on Java application, guys. So I beg your pardon. So we have an access to
[26:41.000 --> 26:48.740]  the source code of the administrator interface. So we are ready to do for the last step,
[26:48.740 --> 26:54.820]  which was finding a vulnerability. There is a different approach to do it, like, you know,
[26:54.820 --> 27:01.740]  top to bottom or bottom to top, you know. Bottom to top means, you know, the potentially vulnerable
[27:02.380 --> 27:08.760]  functions on the Java, let's say, and you can directly search those functions within the code
[27:08.760 --> 27:16.240]  base. And if you believe that you just find a very interesting, very easy way to use those
[27:16.240 --> 27:22.660]  potential vulnerable function, you can start from the bottom to go to the top in order to find out
[27:22.660 --> 27:28.720]  whether you are controlled to parameter that passed through all the function calls. Or you
[27:28.720 --> 27:34.900]  can start from top to bottom, which is like, you know, start by reading the filter or the middle
[27:34.900 --> 27:41.080]  layer definitions and the classes, look for the authentication mechanism, and then search for
[27:41.080 --> 27:49.920]  all the controller or the request handler definition, which will be important because
[27:49.920 --> 27:57.000]  that is the location where you can see the user controller parameters, etc, etc. In that case,
[27:57.000 --> 28:04.920]  I was doing top to bottom approach. I choose that approach because of not very specific reason. I
[28:04.920 --> 28:11.040]  was like, you know, doing fun, funny time on the Sunday and I was just start reading the source
[28:11.040 --> 28:19.020]  code and it was like a top to bottom approach. I wish I could show you all the code bases and
[28:19.020 --> 28:25.220]  everything, but I believe I don't have enough time to do it. So I just grabbed a very specific
[28:25.220 --> 28:36.940]  function definition, which name is a mount device. It has to be a post request to be able to execute
[28:36.940 --> 28:44.320]  the function definition. And there is a very interesting if statement in here. It tells you
[28:44.320 --> 28:50.340]  if the request is coming from the localhost, it is okay. But if the request is not coming from
[28:50.340 --> 28:56.720]  localhost, I'm going to validate your session and your privilege as well. Since we don't have
[28:56.720 --> 29:02.720]  the username, the password, you know, this is going to be a problem for us because it is a
[29:02.720 --> 29:09.420]  password protection if the request is not coming from localhost. And there is a function call in
[29:09.420 --> 29:16.560]  here, get token, which will have a very important role on our exploitation. We will come back later.
[29:16.560 --> 29:24.580]  So that was the important part of the function, and we are moving to the more important stuff.
[29:24.680 --> 29:31.020]  So it tells us that the request must be a post request, and the post body, it is taken
[29:31.020 --> 29:36.440]  from the request, and it is a JSON object. And we're going to get the mount device string from the
[29:37.520 --> 29:45.500]  JSON data, and that part is quite interesting because it performs some sort of escaping. So
[29:46.060 --> 29:53.500]  if the mount device contains a double quote, it will be escaped. If it contains a backtick,
[29:53.500 --> 30:01.280]  dollar sign, it will be escaped by the backslash. But the problem is, if it contains backslash,
[30:01.280 --> 30:07.300]  it will escape backslash one more time. So if we have a double quote, it will be escaped one time,
[30:07.300 --> 30:12.640]  and it will be escaping backslash one more time in here. There is some sort of problem in here.
[30:12.640 --> 30:19.080]  And after that, there is a function call, which is an IsVioletMountDevice,
[30:19.080 --> 30:25.440]  and it takes our parameter that we can control. And if we manage to pass that if statement,
[30:25.440 --> 30:32.660]  we are going to see Exe UI help with CMD, which is tend to execute operating system
[30:34.260 --> 30:40.580]  command with a parameter that we are controlled. So we need to skip that if statement. It has to
[30:40.580 --> 30:49.380]  be returned true. So let's have a look at that one. IsVioletMountDevice, it is just like a very
[30:49.380 --> 30:55.120]  weak blacklisting. It tells you it cannot be contained bash, bin as such, Python, slash,
[30:55.120 --> 31:02.940]  Perl, Python, et cetera, et cetera. It validates, it performs some sort of blacklisting on that
[31:02.940 --> 31:09.800]  bounce. But the problem is, it has the white space at the beginning of the Perl and the Python
[31:09.800 --> 31:15.780]  command in here. So it's a very weak blacklisting. We can bypass that without having any problem.
[31:15.900 --> 31:20.820]  So we have to keep that in our minds if we've managed to find a vulnerability.
[31:21.180 --> 31:28.600]  So all right, we can pass that part and we can reach in here. So it is time to read the Exe UI
[31:28.600 --> 31:38.980]  helper CMD. And Exe UI helper CMD, it is going to execute UI helper binary with a sub-CMD, which is
[31:39.780 --> 31:48.140]  a command that we can control. So what is UI helper? It is located in here and it has a root
[31:48.140 --> 31:53.880]  privilege and there is a suidb. So all the commands will be executed with a root user.
[31:53.880 --> 32:00.620]  So if you find a way to execute our command, that command will be executed with the root privileges,
[32:00.620 --> 32:08.060]  which is something very, very important for us. And finally, that function calls Exe CMD, which is
[32:09.120 --> 32:16.360]  basically calls runtime.getRuntime.exe. So obviously, we have command injection
[32:16.360 --> 32:23.440]  vulnerability in here. So we believe that we have the vulnerability in here and we need to do the
[32:23.440 --> 32:28.340]  proof of concept. Thanks to the reading of funny manual and the product feature steps of the
[32:28.340 --> 32:38.360]  methodology, we know where is which administrator interface, I mean, which many of them it is going
[32:38.360 --> 32:43.480]  to execute that specific endpoint. Of course, you can build it from scratch, but this is more
[32:43.480 --> 32:51.300]  easier for me. And as you can see, that is the post request and there is a month device and we
[32:51.300 --> 32:59.220]  can inject our command in here because the dollar sign, it will be used for the execution and the
[32:59.220 --> 33:04.320]  dollar sign escape one time and the backslash escape one more time, which means there is no
[33:04.320 --> 33:10.200]  at all. That backslash escaping did another one and there is nothing related with the dollar sign,
[33:10.200 --> 33:16.160]  which will be helping us to inject our command. So basically, we are executing sleep command with
[33:16.280 --> 33:23.880]  a 15 seconds with administrator with a root privilege. So let's talk about the exploitation
[33:23.880 --> 33:33.180]  of that vulnerability as well. I'm one of the Metasploit contributors and I usually, you know,
[33:33.180 --> 33:40.040]  using the Python dropper for the exploitation, especially exploiting the Linux machines.
[33:40.040 --> 33:46.780]  But there's a problem about the Python dropper from the MSF Venom of the Metasploit. It has to
[33:47.340 --> 33:54.940]  include the double code that wraps up our dropper command in order to pass it to the Python process.
[33:54.940 --> 34:00.460]  So that means we're not going to be able to directly use it because, as you know, the double
[34:00.460 --> 34:08.620]  code has been escaped on the backend service. So the idea is that we can use Perl because Perl can
[34:08.620 --> 34:17.420]  take a parameter with a single code, which is allowed to use. And basically, the idea is simple.
[34:17.420 --> 34:26.040]  I want to execute Python dropper, but I'm gonna put that Python command into the Perl command. So
[34:26.040 --> 34:31.600]  basically, during the exploitation, we are going to execute Perl, which is going to execute the
[34:31.600 --> 34:37.060]  first step of the Python dropper. When the Python executes, it communicates with the handler,
[34:37.060 --> 34:41.400]  and the handler sends the second stage. So there is, you know, lots of execution,
[34:41.400 --> 34:48.860]  one and after. And there is a Ruby code, as you can see in here, that we can build a Perl command,
[34:48.860 --> 34:53.540]  which includes, which contains our Python command. So it's a quite nice trick.
[34:54.470 --> 35:00.700]  So I reported that vulnerabilities to the ZDI. And of course, ZDI told me that the authentication
[35:00.700 --> 35:06.960]  is required to exploit that vulnerability, but we are going to see that the exploitation can
[35:06.960 --> 35:16.060]  be bypassed, guys. So we have to bypass authentication. Those are the initial ideas.
[35:16.060 --> 35:20.800]  We can find a stored cross-site scripting vulnerability because we can force the
[35:20.800 --> 35:28.700]  user to send HTTP requests to the device endpoint where we have the command injection.
[35:28.700 --> 35:38.380]  And since the user is going to be manipulated by JavaScript, that request will be sent to the
[35:38.380 --> 35:44.350]  endpoint with the authenticated user. So we don't have to be thinking about authentication request,
[35:44.350 --> 35:51.250]  authentication stuff. And another idea is it would be handy to find something,
[35:51.250 --> 35:57.470]  SSH vulnerability, some sort of, some type of SSH vulnerability could be handy in order to
[35:57.470 --> 36:04.590]  communicate with internal services so that we can send a request from the localhost to the endpoint,
[36:04.590 --> 36:11.530]  or it can go directly after the authentication bypass. I don't have too much time. I'm just
[36:11.530 --> 36:18.470]  going to show you how I find a stored cross-site scripting on the administrative interface.
[36:18.470 --> 36:25.350]  So as you can see in here, that is a very basic HTTP request to the proxy service. It tells to
[36:25.350 --> 36:31.550]  the proxy service that I'm going to, you know, that I want to send a GET request to the pentest.blob
[36:31.550 --> 36:38.750]  and proxy service does the job and sends the response back to the user. So that activity
[36:38.750 --> 36:44.050]  has been written into the administrative interface. Guys, remember the Python and
[36:44.050 --> 36:50.390]  Apache Solr stuff that we have talked about 15 minutes ago. You know, that activity
[36:50.390 --> 36:57.370]  has been written to the Apache Solr database, which is represented into the administrative
[36:57.370 --> 37:02.750]  interface. So the idea is that we can control that data in here because we can tell anything
[37:02.750 --> 37:09.210]  we want to the proxy service. So the idea is quite simple. As an attacker, we are going to
[37:09.210 --> 37:17.930]  intentionally download a very, very known malware through the proxy service. So proxy product can
[37:17.930 --> 37:23.530]  detect it and produce a log file and it will be like, you know, ringing all the alarms, you know,
[37:23.530 --> 37:32.150]  I call the malware, etc, etc. But the data will be written into the Apache Solr, which is being
[37:32.150 --> 37:38.370]  used in the administrative interface and very, very specifically in here. So when the system
[37:38.370 --> 37:45.290]  administrator logs in and checks what's happening, we can execute JavaScript code on the
[37:45.290 --> 37:51.870]  system administrator browser. And thanks to that JavaScript code, we can send the IX request to
[37:51.870 --> 37:58.590]  the vulnerable endpoint that we have found in the first place. So, you know, there was a quite
[37:58.590 --> 38:03.930]  interesting XSS vulnerability because whenever the browser is sending requests to the proxy,
[38:03.930 --> 38:09.290]  they are performing the full URL encoding in here. But I'm manually crafting the HTTP request
[38:09.290 --> 38:16.110]  to the proxy service. That means there will be no encoding and that data is not being encoded
[38:16.110 --> 38:22.710]  on the administrator interface. Basically, we have a cross-site scripting, spatially stored
[38:22.710 --> 38:28.710]  cross-site scripting vulnerability in here. So instead of popping up an alert box, we are just,
[38:28.710 --> 38:35.970]  we can just call IX request to the endpoint that we have a command injection. So that was,
[38:35.970 --> 38:42.850]  I reported that vulnerability to the ZDI as well. And as you can see in the vulnerability description,
[38:42.850 --> 38:47.610]  attacker can leverage this in a conjunction with other vulnerabilities to execute code
[38:47.610 --> 38:54.970]  in the context of the root user. But guys, you know, cross-site scripting is cool.
[38:54.970 --> 39:02.730]  I'm not underestimating any kind of vulnerabilities, but it is just not enough for me because there is
[39:02.870 --> 39:09.410]  a huge setback which requires the user interaction for the exploitation. I was like, okay, I just
[39:09.410 --> 39:15.070]  find something very cool, you know, intentional downloading of malware, etc, etc. That idea was
[39:15.070 --> 39:23.590]  simple and cool, but I need to find a better way to continue the exploitation. But, you know,
[39:23.590 --> 39:31.070]  I got another idea while I was spending a time to find the XSS through the proxy service. So
[39:31.070 --> 39:37.430]  the idea is targeting proxy service itself. So as you can remember from the previous slides,
[39:37.430 --> 39:42.990]  that is the HTTP request, a very simple HTTP request to the proxy service itself. It tells
[39:42.990 --> 39:48.090]  the proxy service that I want to communicate with the Pantheon staff blog. Proxy service
[39:48.090 --> 39:54.830]  sends the request, gets the response, and sends back to the user, right? So what happens if I
[39:54.830 --> 40:01.550]  tell the proxy service that I want you to communicate with yourself? In that case,
[40:01.550 --> 40:07.430]  it told me there is a, you know, self-referential request to proxy are forbidden. And I was like,
[40:07.430 --> 40:14.410]  all right, that means there is some sort of control and lots of if statements in the proxy
[40:14.410 --> 40:19.850]  service itself. What happens if I manage to trick the proxy service to communicate with an
[40:19.850 --> 40:26.750]  internal service? That was the main idea. So that is the function, get end user authentication
[40:27.590 --> 40:33.150]  function. I set a breakpoint in here, which produced exactly the same error message that
[40:33.150 --> 40:40.150]  we have seen in here. And I just sent the same request, and it hit the breakpoint, and it tells
[40:40.150 --> 40:47.150]  you that get user notification or the notification has been called by the prepare proxy loop
[40:47.150 --> 40:51.550]  rejection, which has been called by the handle proxy loop, which has been called by the due
[40:51.550 --> 40:58.890]  processing. So we're going to read all of those functions. So within the due processing, there is
[40:58.890 --> 41:05.550]  one function called, which is an easy reverse proxy. And the function is a member of the proxy
[41:05.550 --> 41:11.230]  config cache. So basically, products try to understand, like, am I being placed as a reverse
[41:11.230 --> 41:17.810]  proxy? And in that case, handle proxy loop has been called, this function that we have seen on
[41:17.810 --> 41:26.990]  the previous slide. And that function calls tm socket address is same ADDR. That is the important
[41:26.990 --> 41:35.110]  part, because that function performs full URL comparison with the URL of the proxy service,
[41:35.110 --> 41:44.550]  with a URL of the user try to communicate. So if it is a same address, it calls prepare proxy
[41:44.550 --> 41:51.650]  loop rejection call, and we are seeing that error message. So I just changed the port number
[41:51.650 --> 41:58.090]  to the Apache Solr service. And due to that changes, there will be a no match in the full
[41:58.090 --> 42:06.390]  URL comparison on the proxy service. And there is administrator interface of the Apache Solr service.
[42:06.530 --> 42:14.890]  I'm just can communicate with it because of a very interesting bug in the proxy service. So
[42:14.890 --> 42:20.650]  I, as you can see in here, I'm allowed to communicate with the Apache Solr service
[42:20.650 --> 42:29.330]  administrator interface. So, all right, that was another very, very, very important vulnerability,
[42:29.330 --> 42:35.790]  because we can, we are going to leverage this vulnerability to the bypass authentication
[42:35.790 --> 42:40.690]  on the systems. And in the end, we're going to chain all of them together, guys. So
[42:42.730 --> 42:48.010]  Apache Solr service in the box, I mean, in the product was very old version,
[42:48.010 --> 42:52.750]  because it's not quite easy to upgrade your third party dependencies like Apache Solr or
[42:52.750 --> 43:00.030]  database servers. And in these type of solutions, it's quite hard to upgrade to newer versions. So
[43:00.030 --> 43:08.170]  that was a very, very old vulnerability in Apache Solr service, but it is exactly what I need.
[43:08.170 --> 43:15.050]  It is arbitrary file read vulnerability. So that is the name of the collection,
[43:15.050 --> 43:21.090]  and there is a replication endpoint. And the command has to be a file content. And you can
[43:21.090 --> 43:27.810]  traverse back to the roots folder, and then you can call whatever you want. And that will give
[43:27.810 --> 43:36.370]  you to reading any content of the file. So at the beginning, I wasn't, there was no way to
[43:36.370 --> 43:41.530]  communicate with the Apache Solr service, but we find a very interesting bug. And by exploiting
[43:41.530 --> 43:50.790]  that bug, we are going to read anything we want. So far, so good. I want you to remind the get
[43:50.790 --> 43:58.690]  token function. You know, it was like way behind of our presentation. Guys, all right. Do you
[43:58.690 --> 44:05.590]  remember that get token function? It is going to help us what we are going to achieve in here.
[44:05.590 --> 44:17.650]  Because, let me, yeah. Because that function takes cookies from the HTTP request, and it returns
[44:17.650 --> 44:25.330]  the value. But the problem is, it prints out the value and the name of the cookies. But the
[44:25.330 --> 44:34.610]  Java application is running by the Tomcat process. So those standard outputs data will be written
[44:34.610 --> 44:42.930]  into the log file, which is a Catalina.auth file. So due to that little function, all of those
[44:42.930 --> 44:49.970]  valid session IDs written into the log file, and we have arbitrary file read vulnerability.
[44:50.330 --> 44:56.250]  So what we are going to do that, we're going to exploit two vulnerabilities together in order
[44:56.250 --> 45:02.750]  to get the content of the Catalina.auth file, which contains the valid session IDs. And then
[45:02.750 --> 45:09.170]  we are going to collect all the session IDs together, and we can go to administrator
[45:09.170 --> 45:17.050]  interface in order to exploit command injection vulnerability with the active session IDs. So
[45:17.490 --> 45:23.590]  the idea is actually quite simple, guys. We are going to, in the first step, we are going to exploit
[45:24.370 --> 45:30.290]  a comparison bug in the proxy service, which helps us to communicate with the Apache
[45:30.290 --> 45:38.230]  solar service that is running within the product itself. And this is a very old software which has
[45:38.430 --> 45:44.670]  a vulnerability, and it is arbitrary file reads. And combination of that vulnerability, we are
[45:44.670 --> 45:51.250]  going to read Catalina.auth file. And we're going to, by using regex, we're going to extract all the
[45:51.250 --> 45:57.430]  session IDs that we have. And there is a check session endpoint. I haven't talked about it
[45:57.430 --> 46:03.250]  because it was quite easy. There is a check session endpoint in the product. We are going to
[46:03.250 --> 46:09.770]  test all the session IDs we have in order to find out whether it is still active or not. And if you
[46:09.770 --> 46:17.910]  find an active session, we are going to exploit the command injection vulnerability, and we are
[46:17.910 --> 46:25.930]  going to be executing operating system commands with a root privilege, which will give us a C2
[46:25.930 --> 46:34.550]  reverse shellcr command and control server. That is the idea. And of course, I have implemented a
[46:34.550 --> 46:41.530]  metasplit module that performs all of those steps automatically. And I have a video for it. I would
[46:41.530 --> 46:53.660]  like to, I guess, yeah, time is good. I guess I still have a minute. So let's see. And by the way,
[46:53.660 --> 47:00.240]  that metasplit module has been merged to the master branch of the metasplit project. You are
[47:00.240 --> 47:06.980]  just, you know, can go and fetch the module and install the product on your lab and, you know,
[47:06.980 --> 47:14.140]  have fun. So when we run, as you can see in here, it's trying to, it exploits reverse process
[47:14.140 --> 47:20.280]  service and extract the katalina.out file. And that was, of course, this is a demonstration.
[47:20.280 --> 47:25.900]  There's only one session ID in the log file and it's inactive. And by using that session ID,
[47:25.900 --> 47:31.460]  it goes to the command injection vulnerability and it executes operating system command,
[47:31.460 --> 47:36.820]  which is a Perl command. Perl command contains a Python command, you know, and all of those steps
[47:36.820 --> 47:44.940]  have been automatically done. And as you can see in here, we have a root session on the back filter
[47:44.940 --> 47:49.700]  solution of the company, guys. That's it. Thank you very much.
